Ever wonder which JavaScript compressor you should use? Or which one can crunch your code down to the smallest size?
The “CompressorRater” allows you to easily play with several of the most popular freely available JavaScript Compressors on your own code, from one web interface.
You can quickly view how much compression all the tools give you both with and without gzip compression, and also view the compressed results directly.
You can also view some statistics of CompressorRater runs against the code in several popular JavaScript libraries. (Note that the compressed output of these libraries has not been tested and may not work. Before switching from a given sanctioned compressor on a given library, make sure you run through all the unit tests for that given library, using the compressed JavaScript!)
The following compression tools are rated:
- JSMin is a conservative compressor, written several years ago by Douglas Crockford. It is considered safe (especially if you verify your code with JSLint first– an excellent thing to do anyway) because it doesn’t attempt to change any variable names.
- Dojo shrinksafe is a very popular Java based JavaScript compressor that parses the JavaScript using the rhino library and crunches local variable names.
- Packer by Dean Edwards, is also a very popular JavaScript compressor, that can go beyond regular compression and also add advanced on-the-fly decompression with a JavaScript runtime piece.
- the YUI Compressor is a newer compressor written by Julien Lecomte, that aims to combine the safety of JSMin with the higher compression levels acheived by Dojo Shrinksafe. Like Dojo shrinksafe, it is written in Java and based on the rhino library.
When a given compression tool has options that you can set to tweak the compressed output, all possible combinations of options are run to show you the effects of the size differences when using those different options. Your compressed results are also viewable under all possible compressor options.
While this tool allows you to quickly test out the different Compressors, you must be sure to test your resultant compressed code diligently because JavaScript compressors aren’t perfect and can introduce subtle bugs.
Using JSLint to clean up your JavaScript code is always a great idea, and I’ve found that it can make your code work much better with any of the compressors.
I hope you find this tool useful! Check back often, because I plan to add some neat new features soon. I’m also looking forward to constructive criticism and comments on how I can improve the tool.
The CompressorRater is located at http://compressorrater.thruhere.net/
Arthur Blake's Blog 
packer is not showing up in the results.
so far, the best compression i have found is using shrinksafe first and then packer
By: wade on 2007-08-29
at 10:24 am
DOH! now i see the warning…. good luck on getting that working
By: wade on 2007-08-29
at 10:25 am
What a fantastic tool, I’m so very glad you did this. Good work Arthur!
I don’t see packer in the results :¬/
YUI Compressor always seems to come out best for me. I’ve been using Packer all this time. Now to switch to YUI Compressor :¬)
By: James Dempster on 2007-08-30
at 8:15 am
Agree with wade – the best results I’ve had is to use shrinksafe then packer.
By: Dave on 2007-08-30
at 8:33 am
As I mentioned on the site, Packer is disabled for now in the dynamic compressor (maybe I should have said it in bigger letters?) I’m sorry about that. I know it would really be nice to have it…
I do have it working, but it’s just too slow! If anyone has any ideas on how to make it run faster, let me know. I’m currently looking into trying to use Java regular expressions in the Rhino engine. Regular Expressions, (which make up the heart of the Packer algorithms) are apparently very slow in Rhino.
Here’s a thread in that direction:
Thanks for your comments.
By: Arthur Blake on 2007-08-30
at 8:59 am
Why don’t you just run packer, client-side, and merge the results
By: Kevin on 2007-09-03
at 1:02 pm
Well, you could just let Packer run on the client … Dean Edwards’ reference implementation does that, too: http://dean.edwards.name/packer/
And — excellent tool you got there. Packer support is really the only thing I miss.
By: Hendrik on 2007-09-04
at 10:13 am
I actually had Packer running on the client that way on one of the earlier versions.
It was still just as slow that way, and because I run multiple combinations of options, it’s even slower (slow enough to cause the browser to give a warning that a script is taking too long to execute on larger JavaScript files).
Also, I have to send the Packer results to the server to get the gzip results (anyone know of a gzip algorithm written in JavaScript?) which just makes it that much more complicated…
But I agree, it kind of sucks to not be able to see the Packer results,
I’ll see if I can split the algorithm into smaller chunks that can be called via setTimeout (to prevent the browser timeout) and to give better feedback on the execution as it is in progress (nobody likes to click a button and wait 5 minutes for something to happen!)
Thanks for your comments!
By: Arthur Blake on 2007-09-04
at 10:22 am
Hi Arthur, could You please add my last project, called MyMin, that uses a different algorithm to compress JavaScript with or without CSS in client as with Python, PHP or C# ?
This project uses a revisited, and partially rewrote, JSmin version to be compatible with conditional comments too and to solve few problems like RegExp returned without variable declaration (function(){return /re’re/}, for example, throws an error in most JSmin implementations I tested)
This project uses a “packer like” algorithm (really personal and totally different from Dean Edwards one) that doesn’t require code strategies and it was able to unpack correctly every kind of good or bad script I tested.
This project goal is to compress both JS and CSS in a single file (or only JS or CSS) mantaining JS diabled browsers compatibility and a good Gzip compression ration even using client compression option.
You can find them in its dedicated site: http://packed.it/ … however, thank You for Compressor Rater page!
Best Regards
By: Andrea Giammarchi on 2007-10-12
at 4:08 pm
Hello Andrea! I’m pretty much sticking to the most “popular” open source compressors that are the most widely known and used.
If there was a *Java* implementation for your compressor, I might consider adding it, because it would be much easier to fit into my server side framework — however due to a number of other projects that I’ve taken on recently, I’m severely limited in time at the moment.
Thanks for your kind words.
P.S. I still plan to add some significant new things to the compressorrater when my schedule allows, so stay tuned!
By: Arthur Blake on 2007-10-13
at 2:44 am
Hi Arthur, I’m not skilled with Java as with other languages I used for MyMin (however I suppose if there’s a C# version, Java one will be not so different) but if You’re interested about MyMin please remember that it has a JavaScript client version too (no stress for your server, You can test / bench them directly in packed.it)
However, I’ll try to find time to create MyMin Java version as soon as I can.
Best regards
By: Andrea Giammarchi on 2007-10-13
at 3:28 am
I have a web site jsutility.pjoneil.net that has a set of tools that can compress Javascript substantially more than any of the tools rated by compressorrater.
If you obfuscate, compact and compress your javascript code, it will come close to gzip results. It’s a little slower than these tools but the results are great
Take a look and see what you think.
By: Pat on 2007-10-16
at 9:12 am
An interesting addition would be execution time. So far I assumed that uncompressed and gzipped scripts are faster evaluated then those packed with Dean’s packer. With that in mind, minifying plus gzipping seems to be the best approach.
By: Jörn Zaefferer on 2007-10-23
at 8:57 pm
Perhaps I missed it, but what are the versions of the various compression tools being used? Are the latest versions being used?
By: guest on 2007-12-31
at 1:25 am
They were the latest versions as of 2007-09-03
Version Numbers are listed when you run a compression:
YUI Compressor 2.1.2
Packer 3.1 (alpha 2)
(JSMin and Dojo Shrinksafe don’t have an identifiable version number as far as I could tell.)
By: Arthur Blake on 2007-12-31
at 12:21 pm
I think it will be better to update all compressors and re-count results. More than half a year passed…
By: dreamwind on 2008-02-11
at 4:15 pm
It’s actually not quite been half a year, but nevertheless, I plan on updating all the compressors and re-count the results as soon as I get a chance to work on it.
Please be patient and hopefully I can get that done within a week or two!
By: Arthur Blake on 2008-02-11
at 4:30 pm
[…] También existen métodos manuales, mediante los cuales, podemos comprimir nuestro JavaScript. JavaScriptMCV The Compressor Rater […]
By: Comprimir JavaScript on 2008-12-30
at 6:51 am